Skip to content

t3code: add server service - #9695

Open
jonocodes wants to merge 1 commit into
nix-community:masterfrom
jonocodes:t3code-server-service
Open

t3code: add server service#9695
jonocodes wants to merge 1 commit into
nix-community:masterfrom
jonocodes:t3code-server-service

Conversation

@jonocodes

Copy link
Copy Markdown
Contributor

Description

Adds a programs.t3code.server sub-module that runs the t3code headless server
as a user service. programs.t3code already manages this tool's configuration
(userSettings, keybindings, clientSettings); this lets you also run it.

The service is defined for both platforms — systemd.user.services on Linux and
launchd.agents on Darwin — mirroring programs.opencode.web.

New options under programs.t3code.server:

  • enable
  • extraPackages — placed on the server's PATH so t3code can shell out to the
    coding-agent / VCS CLIs it drives (git, gh, claude-code, opencode, …)
  • extraArgs — passed to t3 serve (e.g. --host, --port)
  • environmentFile — for secrets, without exposing them in the Nix store

host/port are intentionally not modelled as explicit options: t3 serve
has sensible defaults and accepts them as flags, so they go through extraArgs
(matching programs.opencode.web).

Why programs.t3code.server and not services.t3code

I extended the existing programs.t3code module rather than adding a standalone
services.t3code, for two reasons: (1) programs.t3code already owns this
tool's configuration, so keeping the service in the same module keeps the whole
tool under one namespace; and (2) it mirrors programs.opencode.web, the closest
existing module (a coding-agent tool with config plus an optional web server).

That said, I have no strong opinion here — if you'd prefer this as a
services.t3code module, I'm happy to move it.

Checklist

  • Added a test (tests/modules/programs/t3code/server.nix) asserting the
    generated unit on both Linux (systemd) and Darwin (launchd).
  • nix build .#test-all passes; nixfmt/treefmt clean.
  • New maintainer entry uses the existing nixpkgs jonocodes handle.
  • Change is backwards compatible (opt-in; defaults server.enable = false).

@home-manager-ci
home-manager-ci Bot requested a review from iamanaws July 21, 2026 21:47
@jonocodes

Copy link
Copy Markdown
Contributor Author

Pushed an empty commit to re-trigger CI.

The only failing check was on the aarch64-darwin nixbot builder, and the sole failing derivation there is livekit-libwebrtc-137-unstable-2026-03-12 — a transitive dependency of the t3code package (Electron/WebRTC), unrelated to this change. It dies during the final WebRTC framework link with a linker crash (ld ... Trace/BPT trap: 5, clang++: error: linker command failed with exit code 133), i.e. a toolchain-level crash rather than a build-logic error.

The t3code service derivations themselves build fine on that same builder — including the Darwin launchd test (org.nix-community.home.t3code.domain), which generates the plist and byte-compares it against the committed fixture. All GitHub Actions tests (ubuntu + macos) also pass.

@iamanaws — do you know if t3code currently builds on the Darwin builder on master? If this livekit-libwebrtc link failure is a known/flaky platform issue rather than something in this PR, a maintainer restart of the nixbot build would confirm.

Add a `programs.t3code.server` sub-module that runs the t3code headless
server as a user service — systemd on Linux, launchd on Darwin — mirroring
programs.opencode.web. It exposes `enable`, `extraPackages`, `extraArgs`,
and `environmentFile`.
@jonocodes
jonocodes force-pushed the t3code-server-service branch from 8a17782 to 310ddb1 Compare July 22, 2026 05:05
@jonocodes

Copy link
Copy Markdown
Contributor Author

Update: the empty commit was a no-op — nixbot is content-addressed, so an identical tree just replayed build #258's cached result. Rebased onto current master (6d8d61567) instead and dropped the empty commit, which forces a genuinely fresh build. flake.lock/nixpkgs is unchanged vs the previous base, so this won't pull a different livekit-libwebrtc — it only re-attempts the link, which will tell us whether that darwin linker crash is flaky or deterministic.

@jonocodes

Copy link
Copy Markdown
Contributor Author

Conclusive on the darwin failure: the rebase forced a fresh build (#264, 26 derivations rebuilt), and it fails on the exact same livekit-libwebrtc-137-unstable-2026-03-12 with the identical signature —

FAILED: obj/sdk/mac_framework_objc_shared_library/WebRTC ...
cctools-binutils-darwin-1010.6/bin/ld: line 292: Trace/BPT trap: 5
clang++: error: linker command failed with exit code 133

Two independent from-scratch builds (#258 and #264) crash byte-for-byte the same way, so this is deterministic, not a flake. It's the Darwin ld (cctools 1010.6) segfaulting while linking the WebRTC framework — a t3code package dependency pulled from the pinned nixpkgs, not anything this PR adds. All t3code service derivations build fine; the only failing drv is livekit-libwebrtc.

So no author-side retrigger or change will clear this — the fix has to come from nixpkgs (a livekit-libwebrtc/cctools/toolchain bump). @iamanaws, since GH Actions (ubuntu + macos) all pass and the darwin failure is this unrelated linker crash, is this OK to merge, or is t3code currently expected to build on the darwin builder (in which case master is presumably red there too)? Happy to do whatever you prefer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant